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REMARKS/ARGUMENTS 

Favorable reconsideration of this application as presently amended and in light of the 
following discussion is respectfully requested. 

Claims 1-13 are pending, Claims 1-12 having been amended and Claim 13 added by 
way of the present amendment. Claim 13 finds support in the originally filed specification 
and claims and thus no new matter is added. 

In the outstanding Office Action Claims 1-6 were rejected under 35 U.S.C. § 101; 
Claims 1, 2, 7 and 8 were rejected as being anticipated by Perkins (IEEE Communications 
Magazine, May 1997, pages 84-99, entitled "Mobile IP"); and Claims 9-12 were indicated as 
containing allowable subject matter. 

Applicants appreciatively acknowledge the identification of allowable subject matter. 

In reply, Claims 1-6 have been amended to be directed to a packet signal for use in a 
packet communication network. Because a "signal" is an article of manufacture, it is 
respectfully submitted that Claims 1-6, as amended, comply with 35 U.S.C. § 101. Claim 9 
has been written in independent form and thus it is respectfully submitted that Claims 9-12, 
as amended, are in condition for formal allowance. 

Claim 1 is directed to a packet signal for use in a packet communication network for 
transmitting a packet to a mobile terminal through the packet communication network. The 
network includes a plurality of routers inclusive of communication routers configured to 
communicate with mobile terminals through radio communications. The packet signal 
includes destination information configured to identify a packet destination by a state of a 
mobile terminal for transmission of the packet to any number of mobile terminals which are 
in agreement with the state of a mobile terminal. 

As a non-limiting example, the state of a mobile terminal may include things such as a 
speed of movement, a temperature, a humidity, etc. The packet that identifies a destination 
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by such state of a mobile terminal is delivered to any number of mobile terminals having a 
state that matches the state of the mobile terminal. 

Perkins is directed to a device that provides route optimization, using a "care-of 
address" for a mobile terminal located in a foreign network that is different from a home 
network. Moreover, Perkins describes a system in which information is used that is 
indicative of whether the mobile terminal is located in a foreign network or a home network. 
In contrast to the invention defined by amended Claim 1 , Perkins does not teach including 
information configured to identify a packet destination by a state of a mobile terminal for 
transmission of the packet to any number of mobile terminals which are in agreement with 
the state of a mobile terminal. Consequently, it is respectfully submitted that Claim 1 as 
amended patentably defines over Perkins . Because Claims 2-6 depend from Claim 1 it is 
respectfully submitted that these claims also patentably define over Perkins . 

Claim 7 is a method claim that, like Claim 1 above (although a different statutory 
class), includes a feature of identifying a packet destination by a state of a mobile terminal for 
transmission of the packet to any number of mobile terminals which are in agreement with 
the state of a mobile terminal. Thus as was discussed with regard to amended Claim 1, it is 
respectfully submitted that Perkins does not teach this aspect of amended Claim 7 nor 
amended Claim 8, which depends from Claim 7. Consequently it is respectfully submitted 
that Claims 7 and 8 also patentably define over Perkins . 

Claim 13 is directed to a method claim that is a method for creating a packet. Steps in 
the method claim include specifying a destination of the packet by a state of the mobile 
terminal and generating a packet inclusive of information identifying the destination of the 
packet by the state of a mobile terminal for transmission to any number of mobile terminals 
which are in agreement with the state of a mobile terminal. Accordingly, for substantially the 
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same reasons as discussed above with regard to amended Claims 1 and 7, it is respectfully 
submitted that new Claim 13 also patentably defines over Perkins . 

Consequently, in view of the present amendment and in light of the foregoing 
comments, it is respectfully submitted that the invention defined by Claims 1-13, as amended, 
is statutory subject matter, and patentably distinguishing over the prior art. The present 
application is therefore believed to be in condition for formal allowance and an early and 
favorable reconsideration of this application is therefore requested. 



Respectfully submitted, 
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Abstract 

Mobile IP has been designed within the IETF to serve the needs of the burgeoning population of mobile computer users who wish to 
connect to the Internet and maintain communications as they move from place to place. The basic protocol is described, with details 
given on the three major component protocols: Agent Advertisement Registration, and Tunneling. Then route optimization procedures 

are outlined, and further topics of current interest are described. 



Mobile IP 

Charles E. Perkins, Sun Microsystems 
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ecent years have seen an explosive growth both in the 
m 1 number of laptop and notebook computers sold, and 
in the number of nodes connected to the Internet and the 
World Wide Web. The notebook computers are themselves 
ever more powerful, equal in processing capability to many 
systems sold as desktop workstations. In fact, the future 
growth of the Internet is likely to be fueled in large part by 
these very notebook computers, since they account for the 
part of the computer market that is growing fastest. 

Along with these trends, we also see the steady growth of 
the market for wireless communications devices. Such devices 
can only have the effect of increasing the options for making 
connections to the global Internet. Mobile customers can find 
a wide array of such wireless devices available. There are 
numerous varieties of radio attachments and infrared devices; 
of course, communications by way of the cellular telephone 
network is always an option for those willing to pay the fees. 

Mobility vs. Portability 

These trends are motivating a great deal of interest in making 
sure that mobile wireless computers can attach to the Internet 
and remain attached to the Internet even as they move from 
place to place, establishing new links and moving away from 
previously established links. Early on, it was apparent that 
solving the problem at the network layer (say, by modifying IP 
[1], the Internet Protocol, itself) would provide major bene- 
fits, including application transparency and the possibility of 
seamless roaming. Application transparency is almost required 
for all reasonable solutions, because it is unacceptable to 
force mobile users to buy all new mobile-aware applications. 
Seamless roaming, while not yet mandatory, is nonetheless 
expected to register very high on the scale of user conve- 
nience factors once the physical wireless means for continued 
connectivity are widely deployed. Moreover, seamless roaming 
provides application transparency. Mobile IP is the only cur- 
rent means for offering seamless roaming to mobile comput- 
ers in the Internet. It has recently progressed along the ladder 
to standardization within the Internet Engineering Task Force 
(IETF), and its specification is now available as Request for 
Comments (RFC) 2002 [2], Related specifications are avail- 
able as RFCs 2003-2006. 

This article follows the logical outline indicated below. We 
first describe the problem that is solved by mobile IP in the 
next section. In the second section there is a list of terminolo- 
gy and an overview of mobile IP. In the third section, the dis- 



covery mechanisms of mobile IP are described in detail. Fol- 
lowing that, the mechanisms are described by which a mobile 
computer is located. Next, the available tunneling mechanisms 
are shown, which the home agent uses to forward datagrams 
from the home network to the mobile computer. 

Having covered the details of the base mobile IP specifica- 
tion, we then describe further protocol messages which help 
to decrease the inefficiency associated with inserting the home 
agent in the routing path of data destined for mobile comput- 
ers. This route optimization is still a topic for further work 
within the IETF. Finally, we summarize and discuss the cur- 
rent problems facing mobile IP, as well as a few areas of 
active protocol development. 

Mobile IP Overview 

Mobile IP can be thought of as the cooperation of three 
major subsystems. First, there is a discovery mechanism 
defined so that mobile computers can determine their new 
attachment points (new IP addresses) as they move from 
place to place within the Internet. Second, once the mobile 
computer knows the IP address at its new attachment point, it 
registers with an agent representing it at its home network. 
Lastly, mobile IP defines simple mechanisms to deliver data- 
grams to the mobile node when it is away from its home net- 
work. 

Why Isn't Mobility Simple? 

Consider how IP addresses are used today in the Internet. In 
the first place, they are primarily used to identify a particular 
end system. In this respect, IP addresses are often thought of 
as being semantically equivalent to Domain Name Server's 
(DNS's) Fully Qualified Domain Names (FQDNs). In other 
words, one can (conceptually) use either an IP address or 
FQDN to identify one particular node out of the tens of mil- 
lions of computer nodes making up the Internet. Popular 
transport protocols such as Transmission Control Protocol 
(TCP) [3] keep track of their internal session state between 
the communicating endpoints by using the IP address of the 
two endpoints, stored along with the demultiplexing selectors 
for each session, that is, the port numbers. 

However, IP addresses are also used to find a route 
between the endpoints. The route does not have to be the 
same in both directions. Modeling the session as a bidirection- 
al byte stream, the IP destination address for datagrams going 
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in one direction would be the same as the IP source address 
for datagrams going in the opposite direction. Typically, the 
route selected for a datagram depends only on the IP destina- 
tion address, and not (for example) on the IP source address, 
time of day, or length of the payload. The only other factor 
usually influencing route selection is the current state of net- 
work congestion. In other words, a route that might usually be 
selected by an intermediate router for a particular destination 
may go out of favor if traffic along that direction is delayed or 
dropped because of congestion. 

Putting these two uses together results in a situation fraught 
with contradiction for mobile computing. On one hand, a 
mobile computer needs to have a stable IP address in order to 
be stably identifiable to other Internet computers. On the 
other hand, if the address is stable, the routing to the mobile 
computer is stable, and the datagrams always go essentially to 
the same place — thus, no mobility. Mobile IP extends IP by 
allowing the mobile computer to effectively utilize two IP 
addresses, one for identification, the other for routing. 

Some attempts have been made to manage the movement 
of Internet computers by less functional methods. For starters, 
it is certainly possible, given sufficient deployment of DHCP 
[4, 5], for a mobile node to get an IP address at every new 
point of attachment. This will work fine until the mobile node 
moves somewhere else. Then the old address will no longer be 
of use, and the node will have to get another one. Unfortu- 
nately, this approach usually also means that every established 
IP client on the mobile node will stop working, so the mobile 
node will have to restart its Internet subsystems. Many users 
will not be so selective, and will just reboot their system. This 
isn't so bad if each new point of attachment is separated by 
some time during which the system is disconnected or turned 
off anyway. Many mobile computer users are satisfied with just 
that mode of operation, which we'll describe as portability. 

Even with portable operation, however, there are other big 
difficulties. Most applications initially identify an Internet 
node by means of its FQDN, but subsequently only make use 
of the node's IP address. In order to contact the node, the 
application consults the appropriate DNS server to get an IP 
address. If the IP address is allocated dynamically, either the 
server will have it wrong, or the server will need to get updates 
(say, from the portable Internet node). Since DNS is typically 
at the administrative heart at most networked enterprises 
using the Internet, any protocols designed to alter the data 
are going to have to be extremely well designed, implemented, 
and administered. The more often updates are applied to 
DNS records [6], and the more platforms involved in hosting 
the update protocol implementation, the more likely that 
things are going to go haywire in a big, expensive meltdown. 
At minimum, one can be confident that a lot more work is 
going to be necessary before system administrators learn to 
trust that thousands (or millions!) of mobile nodes can reli- 
ably reach into the guts of their enterprise operations and 
tweak a record or two here and there. Much of this work will 
involve precisely carrying out certain cryptographic techniques 
that are only now being standardized for use with DNS [7]. 

Terminology 

Before getting into more details, it is a good idea to frame the 
discussion by setting some terminology, adapted from the 
mobile IP specification [2]. Mobile IP introduces the following 
new functional entities: 

Mobile node — A host or router that changes its point of 
attachment from one network or subnetwork to another, with- 
out changing its IP address. A mobile node can continue to 
communicate with other Internet nodes at any location using 
its (constant) IP address. 



Home agent — A router on a mobile node's home network 
which delivers datagrams to departed mobile nodes, and 
maintains current location information for each. 

Foreign agent — A router on a mobile node's visited net- 
work which cooperates with the home agent to complete the 
delivery of datagrams to the mobile node while it is away from 
home. 

A mobile node has a home address, which is a long-term IP 
address on its home network. When away from its home net- 
work, a care-of address is associated with the mobile node and 
reflects the mobile node's current point of attachment. The 
mobile node uses its home address as the source address of all 
IP datagrams it sends, except where otherwise required for cer- 
tain registration request datagrams (e.g., see the fourth section). 

The following terms are frequently used in connection with 
mobile IP: 

Agent advertisement — Foreign agents advertise their 
presence by using a special message, which is constructed by 
attaching a special extension to a router advertisement [8], as 
described in the next section. 

Care-of address — The termination point of a tunnel 
toward a mobile node, for datagrams forwarded to the mobile 
node while it is away from home. There are two different 
types of care-of address: a foreign agent care-of address is an 
address of a foreign agent with which the mobile node is reg- 
istered; a collocated care-of address is an externally obtained 
local address which the mobile node has associated with one 
of its own network interfaces. 

Correspondent node — A peer with which a mobile node 
is communicating. A correspondent node may be either 
mobile or stationary. 

Foreign network — Any network other than the mobile 
node's home network. 

Home address — An IP address that is assigned for an 
extended period of time to a mobile node. It remains 
unchanged regardless of where the node is attached to the 
Internet. 

Home network — A network, possibly virtual, having a net- 
work prefix matching that of a mobile node's home address. 
Note that standard IP routing mechanisms will deliver data* 
grams destined to a mobile node's home address to the 
mobile node's home network. 

Link — A facility or medium over which nodes can com- 
municate at the link layer. A link underlies the network layer. 

Link-layer address — The address used to identify an end- 
point of some communication over a physical link. Typically, 
the link-layer address is an interface's media access control 
(MAC) address. 

Mobility agent — Either a home agent or a foreign agent. 

Mobility binding — The association of a home address 
with a care-of address, along with the remaining lifetime of 
that association. 

Mobility security association — A collection of security 
contexts between a pair of nodes which may be applied to 
mobile IP protocol messages exchanged between them. Each 
context indicates an authentication algorithm and mode (as 
described in the fourth section), a secret (a shared key, or 
appropriate public/private key pair), and a style of replay pro- 
tection in use. 

Node — A host or a router. 

Nonce— A randomly chosen value, different from previous 
choices, inserted in a message to protect against replays. 

Security parameters index (SPI) — An index identifying a 
security context between a pair of nodes among the contexts 
available in the mobility security association. 

Tunnel — The path followed by a datagram while it is 
encapsulated. The model is that, while encapsulated, a data- 
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■ Figure 1 . Mobile IP datagram flow. 



gram is routed to a knowledgable agent, which decapsulates the 
datagram and then forwards it along to its ultimate destination. 

Virtual network — A network with no physical instantia- 
tion beyond its router (with a physical network interface on 
another network). The router (e.g., a home agent) generally 
advertises reachability to the virtual network using conven- 
tional routing protocols. 

Visited network — A network other than a mobile node's 
home network to which the mobile node is currently connected. 

Visitor list — The list of mobile nodes visiting a foreign agent. 

Protocol Overview 

Mobile IP is a way of performing three related functions: 

Agent Discovery — Mobility agents advertise their avail- 
ability on each link for which they provide service. 

Registration — When the mobile node is away from home, 
it re&sters its care-of address with its home agent. 

Tunneling — In order for datagrams to be delivered to the 
mobile node when it is away from home, the home agent has 
to tunnel the datagrams to the care-of address. 

The following will give a rough outline of operation of the 
mobile IP protocol, making use of the above-mentioned oper- 
ations. Figure 1 may be used to help envision the roles played 
by the entities. 

• Mobility agents make themselves known by sending agent 
advertisement messages. An impatient mobile node may 
optionally solicit an agent advertisement message. 

• After receiving an agent advertisement, a mobile node 
determines whether it is on its home network or a for- 
eign network. A mobile node basically works like any 
other node on its home network when it is at home. 

• When a mobile node moves away from its home network, 
it obtains a care-of address on the foreign network, for 
instance, by soliciting or listening for agent advertise- 
ments, or contacting Dynamic Host Configuration Proto- 
col (DHCP) or Point-to-Point Protocol (PPP). 

• While away from home, the mobile node registers each 
new care-of address with its home agent, possibly by way 
of a foreign agent. 

• Datagrams sent to the mobile node's home address are 
intercepted by its home agent, tunneled by its home agent 
to the care-of address, received at the tunnel endpoint 
(at either a foreign agent or the mobile node itself), and 
finally delivered to the mobile node. 

• In the reverse direction, datagrams sent by the mobile 
node are generally delivered to their destination using 
standard IP routing mechanisms, not necessarily passing 
through the home agent (but see the eighth section). 
When the home agent tunnels a datagram to the care-of 

address, the inner IP header destination (i.e., the mobile 
node's home address) is effectively shielded from intervening 
routers between its home network and its current location. At 
the care-of address, the original datagram exits from the tun- 
nel and is delivered to the mobile node. 

It is the job of every home agent to attract and intercept 
datagrams that are destined to the home address of any of its 



registered mobile nodes. The home agent basically does this 
by using a minor variation on proxy Address Resolution Protocol 
(ARP), and to do so in the natural model it has to have a net- 
work interface on the link indicated by the mobile node's home 
address. However, the latter requirement is not part of the 
mobile IP specification. When foreign agents are in use, simi- 
larly, the natural model of operation suggests that the mobile 
node be able to establish a link its foreign agent. Other con- 
figurations are possible, however, using protocol operations 
not defined by (and invisible to) mobile IP. Notice that, if the 
home agent is the only router advertising reachability to the 
home network, but there is no physical link instantiating the 
home network, then all datagrams transmitted to mobile 
nodes addressed on that home network will naturally reach 
the home agent without any special link operations. 

Figure 1 illustrates the routing of datagrams to and from a 
mobile node away from home, once the mobile node has reg- 
istered with its home agent. The mobile node is presumed to 
be using a care-of address provided by the foreign agent: 

• A datagram to the mobile node arrives on the home net- 
work via standard IP routing. 

• The datagram is intercepted by the home agent and is 
tunneled to the care-of address, as depicted by the arrow 
going through the tube. 

• The datagram is detunneled and delivered to the mobile 
node. 

• For datagrams sent by the mobile node, standard IP rout- 
ing delivers each to its destination. In the figure, the for- 
eign agent is the mobile node's default router. 

Now, we will go into more detail about the various parts of 
the protocols outlined above. 

Mobile Agent Discovery 

rhe process of detecting a mobility agent is quite similar to 
that used by Internet nodes to detect routers running 
Internet Control Message Protocol (ICMP) Router Discovery 
(RFC 1256) [7]. The basic operation involves periodic broad- 
casts of advertisements by the routers onto their directly 
attached subnetworks. Noticing the similarity, the Mobile IP 
working group decided to use RFC 1256 directly, and support 
the special additional needs of mobility agents by attaching 
special extensions to the standard ICMP [9] messages. 

Agent Advertisement 

ey far the most important extension is the mobility agent 
extension, which is applied to ICMP Router Advertise- 
ment and illustrated in Fig. 2. 

The flags (R, B, H, F, M, G, and V) inform mobile nodes 
regarding special features of the advertisement, and are 
described below. The type field allows mobile nodes to distin- 
guish between the various kinds of extensions which may be 
applied by mobility agents to the ICMP Router Advertise- 
ments; the type for the mobility agent advertisement extension 
is 3. Other extensions may, of course, precede or succeed this 
extension; almost no other extensions are defined as of this 
writing. The length field is the length of this single extension, 
which really only depends on how many care-of addresses are 
being advertised. Furthermore, currently, at most one care-of 
address will typically be advertised (see the eighth section). 
Home agents do not have to advertise care-of addresses, but 
they still need to broadcast mobility agent advertisements so 
that mobile nodes will know when they have returned to their 
home network. Indeed, mobility agents can advertise care-of 
addresses even when they do not offer any default router 
addresses, as would be found in other ICMP Router Adver- 
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tisements. No preferences apply to adver- 
tised care -of addresses. 

The flags are defined as follows: 
R Registration required. Registration 

with this foreign agent (or another 

foreign agent on this link) is 

required, even if using a collocated 

care-of address. 
B The foreign agent is busy. 
H The agent is a home agent. 
F The agent is a foreign agent. 
M Minimal encapsulation (RFC 2004 [10]) 
G GRE encapsulation (RFC 1701 [11]) 
V Van Jacobson header compression (RFC 1144 [12]) 

Note that bits F and H are not mutually exclusive, and that 
B cannot be set unless F is also set. Note also that a foreign 
agent typically needs to continue sending advertisements out 
(with the B bit set), even though it is too busy to provide ser- 
vice to new mobile nodes. Otherwise, the foreign agent's cur- 
rent customers might think the foreign agent had crashed, and 
move away unnecessarily. 

The mobility agent generally increments the sequence 
number by one for each successive advertisement. Special 
rules enable a mobile node to distinguish between foreign 
agent crashes, and wraparound of the sequence number field. 

Agent Solicitation 

A mobile node is allowed to send ICMP Router Solicitation 
messages in order to elicit a mobility agent advertisement. 

There are two kinds of registration messages, the registra- 
tion request and registration reply, both sent to User Data- 
gram Protocol (UDP) port 434. The overall data structure of 
the registration messages is shown in Fig. 3. The request mes- 
sage allows the mobile node to inform its home agent of its 
current care-of address, tells the home agent how long the 
mobile node wants to use the care-of address, and indicates 
special features that may be available from the foreign agent. 
The foreign agent is considered a passive agent in the regis- 
tration procedure, and agrees to pass the request to the home 
agent, and subsequently to pass the reply from the home 
agent back to the mobile node. 

Registration Request 

The registration process is almost the same whether the 
mobile node has obtained its care-of address from a foreign 
agent, or alternatively has acquired it from another indepen- 
dent service such as DHCP. In the former case, the mobile 
node basically sends the request (with fields filled in as 




Figure 2. Mobility agent extension format 





Figure 3. Data structure of a registration message. 



described below) to the foreign agent, which then relays the 
request to the home agent. In the latter case, the mobile node 
sends its request directly to the home agent, using its collocat- 
ed care-of address as the source IP address of the request. 

After the IP and UDP headers, the registration request has 
the structure illustrated in Fig. 4. 

Given the discussion about the bit fields in the agent 
advertisement extension in the third section, the need for 
most of the fields is clear. The V bit in the request serves to 
inform the foreign agent whether Van Jacobson compression 
is desired. The M and G bits tell the home agent which addi- 
tional encapsulation methods can be used. The B bit is used 
to tell the home agent to encapsulate broadcast datagrams 
from the home network for delivery to the care-of address 
(and from there to the mobile node). The D bit describes 
whether or not the mobile node is collocated with its care-of 
address, and is mainly useful for determining how to deliver 
broadcast and multicast datagrams to the mobile node. 

Also included are the home address and the proposed 
care-of address. The identification field, a 64-bit field, is used 
for replay protection, as described below when security is dis- 
cussed. The most important extension is the mobile-home 
authentication extension, described in the fourth section, 
which is required in every registration in order to allow the 
home agent to prevent fraudulent remote redirects. 

Registration Reply 

The registration reply has the structure illustrated in Fig. 5. 

The lifetime field tells the mobile node how long the regis- 
tration will be honored by the home agent. It can be shorter 
than requested, but never longer. The code field describes the 
status of the registration. If the registration succeeds, well and 
good. If the registration fails, the code field offers details 
about what went wrong. 

Typical values include: 
0 registration accepted 





I Figure 4. Registration request format. 



Registration denied by the foreign 
agent: 

66 insufficient resources 

69 lifetime request > advertised limit 

70 poorly formed request 

71 poorly formed reply 

88 home agent unreachable 

Registration denied by the home agent: 

130 insufficient resources 

131 mobile node failed authentication 

133 registration identification mismatch 

134 poorly formed request 

136 unknown home agent address 
Receiving code 133 usually indicates 
the need for resynchronization between 



IEEE Communications Magazine • May 1997 



91 




2 3 4 5 6 



6 7*^^ 



■ > : Lifetime 



III III 



'ttgi;^T L I..I-.I. I 



i^lpB^ntification 



I I. I I I I 



I I 1 I 1,1 



I I. I . 1 I 



1 I ;i: 1 V- 



I - I I I 1 



I Figure 5. Registration reply format 







£ 2: •."•■ : :3 
6.7 8 9 0 1 2 3 4 5 6 7 :8.;9 0 =1. 






■1 1 1 1 1 A 1 1 1 1 1 l."f t. 1 
SPI ' . ':::. ;* 




V v . Authenticator . r*; * " 



I Figure 6. Mobile IP authentication extensions. 



the home agent and the mobile node. This synchronization 
can be either time-based or based on the exchange of ran- 
domly generated nonce values. Note that error code 130 
should effectively be impossible. The home agent should not 
be configured to accept the mobile node if it does not have 
the needed resources. 

Up-to-date values of the code field are specified in the 
most recent assigned numbers (e.g., [13]). 

Dynamic Home Agent Discovery 

Rejection code 136 forms the basis for allowing the mobile 
node to find the address of a home agent when needed. If the 
registration reply is addressed to the directed broadcast 
address, every home agent on the home network should 
receive and reject it. However, the registration reply contain- 
ing the rejection also contains the home agent's address, so 
the mobile node can try again and succeed. 

Securing the Registration Procedure 

Registration in mobile IP must be made secure so that fraud- 
ulent registrations can be detected and rejected. Otherwise, 
any malicious user in the Internet could disrupt communica- 
tions between the home agent and the mobile node by the 
simple expedient of supplying a registration request contain- 
ing a bogus care-of address (perhaps the IP address of the 
malicious user). This would effectively disrupt all traffic des- 
tined for the mobile node. 

The method specified to protect against such malicious 
users involves the inclusion of an unforgeable value along with 
the registration that changes for every new registration. In 
order to make each one different, a timestamp or newly gen- 
erated random number (a nonce) is inserted into the identifi- 
cation field. The home agent and mobile node have to agree 
on reasonable values for the timestamp or nonce, and the pro- 
tocol allows for resynchronization, as described earlier, by use 
of reply code 133. 

There are three authentication extensions defined for use 
with mobile IP, as follows: 

• The mobile-home authentication extension 

• The mobile-foreign authentication extension 

• The foreign-home authentication extension 

As illustrated in Fig. 6, they all have similar formats, distin- 
guishable only by different type numbers. The mobile-home 
authentication extension is required in all registration requests 
and replies. The SPI within any of the authentication exten- 
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sions defines the security context used to 
compute (and check) the authenticator. In 
particular, the SPI selects the authentica- 
tion algorithm and mode, and secret (a 
shared key, or appropriate public/private 
key pair) used to compute the authentica- 
tor. A mobile node has to be able to asso- 
ciate arbitrary SPI values with any 
authentication algorithm and mode it 
implements. SPI values 0 through 255 are 
reserved and not allowed to be used in any 
mobility security association. 

The default authentication algorithm 
uses keyed-MD5 [14] in prefix 4- suffix 
mode to compute a 128 -bit message digest 
of the registration message. The default 
authenticator is a 128-bit message digest 
computed by the default algorithm over 
the following stream of bytes: 
• The shared secret defined by 
the mobility security association 
between the nodes and by SPI value 
specified in the authentication extension, followed by 

• The protected fields from the registration message, in the 
order specified above, followed by 

• The shared secret again 

The authenticator itself and the UDP header are not 
included in the computation of the default authenticator 
value. All implementations of mobile IP are required to 
implement the default authentication algorithm just described. 

Routing and Tunneling 

rhe home agent, after a successful registration, will begin to 
attract datagrams destined for the mobile node and tunnel 
each one to the mobile node at its care-of address. The tun- 
neling can be done by one of several encapsulation algo- 
rithms, but the default algorithm that must always be 
supported is simple IP-within-IP encapsulation, as described 
in RFC 2003 [15]. Encapsulation is a very general technique 
used for many different reasons, including multicast, multipro- 
tocol operations, authentication, privacy, defeating traffic 
analysis, and general policy routing. 

Pictorially, Fig. 7 shows how an IP datagram is encapsulated 
by preceding it with a new IP header (the tunnel header). In 
the case of mobile IP, the values of the fields in the new header 
are selected naturally, with the care-of address used as the des- 
tination IP address in the tunnel header. The encapsulating IP 
header indicates the presence of the encapsulated IP datagram 
by using the value 4 in the outer protocol field. The inner head- 
er is not modified except to decrement the TTL by 1. 

Alternatively, minimal encapsulation [10] can be used as 
long as the mobile node, home agent, and foreign agent (if 
present) all agree to do so. IP-within-IP uses a few more 
bytes per datagram than minimal encapsulation, but allows 
fragmentation at the home agent when needed to deal with 
tunnels with smaller path maximum transmission units 
(MTUs). 

The minimal encapsulation header fits in the same relative 
location within the encapsulated payload, as indicated by the 
old IP header in Fig. 7. The presence of the minimal encapsu- 
lation header is indicated by using protocol number 55 in the 
encapsulating IP header protocol field. Figure 8 shows the 
fields of the minimal encapsulation header, which are 
described below. The length of the minimal header is either 
12 or 8, depending on whether the original source IP address 
is present. 
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Protocol — Copied from the pro- 
tocol field in the original IP header. 

Original Source Address Pre- 
sent (S) — If 1, the original 
source address field (below) is pre- 
sent; otherwise, it is not. 




Figure 7. IP-within-IP encapsulation. 



Reserved — Sent as zero; ignored on reception. 

Header Checksum — The 16-bit l's complement of the l's 
complement sum of all 16-bit words in the minimal forward- 
ing header. For purposes of computing the checksum, the 
value of the checksum field is 0. The IP header and IP pay- 
load (after the minimal forwarding header) are not included 
in this checksum computation. 

Original Destination Address — Copied from the destina- 
tion address field in the original IP header. 

Original Source Address — Copied from the source 
address field in the original IP header. This field is present 
only if the original source address present (S) bit is set. 

Soft Tunnel State 

One unfortunate aspect of ICMP error messages is that they 
are only required by the protocol to incorporate 8 bytes of the 
offending datagram. Therefore, when delivery of a datagram 
tunneled to a care-of address fails, the ICMP error returned 
to the home agent may not contain the IP address of the orig- 
inal source of the tunneled datagram. 

Naturally, it makes sense for the home agent to try to noti- 
fy the correspondent host (the source of the datagram which 
could not be delivered) in this situation. If the home agent 
keeps track of which datagrams have been tunneled to which 
care-of addresses (including the IP sequence number), the 
ICMP error return can be used by the home agent to indicate 
which datagram caused the problem. If that determination is 
made, the ICMP error return can be relayed by the home 
agent to the correspondent node which sent the offending 
datagram. 

When a correspondent node sends the datagram to the 
home network, and the datagram arrives at the home net- 
work, it seems inappropriate for the home agent to relay 
ICMP network unreachable messages without any change. 
In fact, from the point of view of the correspondent node, the 
tunnel should be invisible, almost as if it were an extension of 
the home link. So when the home agent can determine which 
correspondent node should receive the error, it makes sense 
for the home agent to transform the network unreachable 
message into a host unreachable message. 

When the home agent is about to tunnel a datagram to a 
care-of address which has just failed, it is quite feasible for the 
home agent to remember that the tunnel is broken. The home 
agent can then inform the correspondent host directly, using 
an ICMP host unreachable message. In fact, the home 
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agent can keep track of other 
interesting tunnel parameters, 
especially including the path MTU 
for the tunnel and the necessary 
time to live (TTL) for encapsulat- 
ed datagrams using that tunnel. 
This collection of tunnel parame- 
ters is called the soft state of the 
tunnel. The IP-within-IP encapsulation specification, RFC 
2003 [15], recommends maintenance of soft state, and gives 
specific rules for relaying ICMP messages. 

Home Network Configurations 

There are three basic configurations for home networks. The 
first is a standard physical network connected by way of a 
router, with another node on the network acting as a home 
agent. The configuration shown in Fig. 9a will be very popu- 
lar, especially for enterprises starting to use mobile IP. If the 
home agent is also an enterprise router, the physical home 
network layout can be conceptually simpler, as illustrated in 
Fig. 9b. In either case, wireless devices can be configured with 
IP addresses on existing physical (say, Ethernet) networks 
with the help of bridging devices that cause the wireless pack- 
ets to be bridged onto the physical network. 

At the other extreme, it is possible to manage a home net- 
work that has no physical realization, called a virtual network, 
as shown in Fig. 9c. The home agent appears to the rest of the 
Internet as the router for the home network, but when data- 
grams arrive at the home agent, they are never forwarded. 
Instead, the home agent encapsulates them and sends them to 
a known care-of address. 

Proxy and Gratuitous ARP 

In either configuration a or b of Fig. 9, the home agent has to 
perform proxy ARP for the mobile node. Otherwise, existing 
Internet hosts on the home network would not be able to con- 
tact the mobile node after it has moved to some new care-of 
address. 

In fact, hosts remaining on the home network which com- 
municate with the mobile node while it is at home are likely 
to have ARP [16] cache entries for the mobile node that 
become stale the instant the mobile node moves away. For 
this reason, the home agent is required to broadcast gratuitous 
ARPs as soon as the mobile node moves away from its home 
network and registers a new care-of address. The gratuitous 
ARPs are supposed to have the effect of updating the ARP 
caches of every node physically attached to the home network 
so that they resolve the IP home address of the mobile node 
into the link-layer address of the home agent. Similarly, when 
the mobile node returns to its home network, it broadcasts 
gratuitous ARPs so that its home address is again associated 
to its own link-layer address by the other nodes on the home 
network. Networks on which nodes are attached that do not 
work with gratuitous ARP should not be administered as 
home networks. 

Because of the danger of irreparably creating stale ARP 
caches, mobile nodes must never broadcast 
an ARP request or ARP reply packet on 
any visited network. If, for instance, a wire- 
less mobile node were to broadcast an 
ARP request to find the link-layer address 
of the foreign agent broadcasting a care-of 
address, any other wireless stations within 
range could possibly create ARP cache 
entries for that mobile node. Those entries 
would make it hard to contact the mobile 
node after it moves away. 
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Route Optimization 

/y s noted above, datagrams going to the mobile node have 
^Ito travel through the home agent when the mobile node is 
away from home, but datagrams from the mobile node to 
other stationary Internet nodes can instead be routed directly 
to their destinations (Fig. 10). This asymmetric routing, called 
triangle routing, is generally far from optimal, especially in 
cases when the correspondent node is very close to the mobile 
node. 

In this section, we will describe in some detail the neces- 
sary protocol operations (called route optimization) to elimi- 
nate the triangle routing problem. The current protocol 
definition may be found in the Internet draft [17], and there 
are additional details in an earlier paper on the subject [18]. 
The advantages of route optimization are clear. The disadvan- 
tage is that, for the first time, and in major distinction to the 
base mobile IP protocol, changes are required in the corre- 
spondent nodes. 

Route Optimization Overview 

The basic idea underlying route optimization is that the routes 
to mobile nodes from their correspondent nodes can be 
improved if the correspondent node has an up-to-date mobili- 
ty binding (see the second section) for the mobile node in its 
routing table. Most of the proposed protocol described below 
is geared toward providing such an updated mobility binding 
(usually shortened to just binding) to correspondent nodes 
that need them. With an updated binding, the correspondent 
node will be able to send encapsulated datagrams directly to 
the mobile node's care-of address instead of relying on a pos- 
sibly distant home agent to do so. 

Every aspect of the design is influenced by the need to 
allow the correspondent nodes to be sure of the authenticity 
of the updates. Mobile computer users would not be very sat- 
isfied if their traffic were easily hijacked, and their very mobil- 
ity increases the likelihood that aspects of network security at 
their point of attachment may be inadequate. We also have to 
keep in mind that a majority of such nodes, today, will not be 
able to understand the protocol. 

The current unsatisfactory state of security within the 
Internet, and especially the lack of key distribution protocols, 
has determined several further aspects of the design of the 
route optimization protocols. In particular, we believe that for 
the near future while security protocols are still in the early 
stages of development and deployment, correspondent nodes 
are more likely to maintain security relationships with home 
agents than with individual mobile nodes. Observe that mobile 
nodes usually spend time connected to nodes either within 
their home domain or near their current point of attachment. 



For instance, suppose an employee from one enterprise, 
say Home Domains, Inc. (company H), wishes to use mobile 
IP while roaming the premises of another enterprise, say Fly 
Away With Us, Inc. (company F). We expect that the employ- 
ee would, first of all, make sure the administrator of the 
home domain sets up a security association with the admin- 
istrator of the foreign domain at company F. If the enter- 
prises communicate frequently for business purposes (a 
likely circumstance given the employee's need to roam 
there), such a security association might already exist and 
be ready for use. Then we further hope that any relevant 
correspondent node could get the necessary security associ- 
ation needed for communication with company H's home 
agent, perhaps by browsing an administrative panel and 
requesting the necessary information encrypted by its own 
local security transform. 

Following this speculative model of the future, we have 
designed the protocol so that the home agent is responsible 
for providing binding updates to any concerned correspondent 
nodes at foreign enterprises. Briefly, the protocol operates in 
as many as four steps: 

• A binding warning control message may be sent to the 
home agent, indicating a correspondent node that seems 
unaware of the mobile node's care-of address. 

• The correspondent node may send a binding request. 

• The home agent (typically) may send an authenticated 
binding update containing the mobile node's current care- 
of address. 

• For smooth handoffs (sixth section), the mobile node 
transmits a binding update and has to be certain that the 
update was received. Thus, it can request a binding 
acknowledgment from the recipient. 

In the next sections, a brief description of the above mes- 
sage types will be presented. Note that, particularly with the 
binding warning and binding update messages, the sending 
agent must be careful not to blindly send the messages with- 
out regard to past history. If the message has been sent 
recently, and seemingly has had no effect, the natural conclu- 
sion can be drawn that the intended recipient does not under- 
stand route optimization protocol messages. Therefore, the 
sender is obligated to send those messages less frequently in 
the future, or perhaps not at all. The protocol specifies a ran- 
dom exponential backoff mechanism for retransmitting these 
messages. Also note that all reserved fields are ignored on 
reception and must be set to zero upon transmission. Later, a 
brief description of the security architecture currently planned 
to make the above transactions secure is presented. AH mes- 
sages are transmitted by way of UDP. As with the basic 
mobile IP protocol, there is no need for the additional fea- 
tures of TCP. 




■ Figure 1 0. Triangle routing. 
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Binding Warning 

A binding warning message (Fig. 11) 
informs the recipient that the target node 
could benefit from obtaining a fresh bind- 
ing for the mobile node. Usually, the recip- 
ient is the home agent, which is likely to be 
known to the sender because the sender 
obtained its binding from the home agent 
in the first place. 

Binding Request 

Any time a correspondent node determines 
that its binding is stale, or is going stale, it 
can issue a binding request message (Fig. 12) 
to the home agent. The correspondent node 
sends a 64-bit number (the identification) to 
the home agent for use in protecting against 
replay attacks, and also to help match pend- 
ing requests with subsequent updates. 



Binding Updates 

The home agent (typically) sends a binding 
update message (Fig. 13) to those corre- 
spondent nodes that need them. This often happens because 
the home agent has received a datagram addressed to a 
mobile node from the correspondent node, which subsequent- 
ly has to be tunneled by the home agent to the mobile node's 
current care-of address. If the home agent has a security rela- 
tionship with the correspondent node, it can send a binding 
update straightaway without waiting for any binding warning 
or binding request. As with any binding, the binding included 
in the update must contain an associated lifetime, after which 
the binding is to be purged by the recipient. 

Notice that the correspondent node may be willing to use 
minimal encapsulation or GRE to tunnel datagrams to the 
mobile node. The home agent sets the appropriate bits (M or 
G) to notify the correspondent node that the respective 
encapsulation protocols may be used if desired. The A bit is 
used to request an acknowledgment, and the I bit is set if the 
identification field is present. Cases involving smooth handoff 
require acknowledgments. On the other hand, the home agent 
usually finds out if the correspondent node has not gotten the 
update yet, just by the fact that it still has to encapsulate data- 
grams from that correspondent node sent to the mobile node. 

The binding update must be accompanied by the route 
optimization authentication extension, similar to the mobile- 
home authentication extension. 

Binding Acknowledgment 

The binding acknowledgment message (Fig. 14) is used to 
acknowledge the reception of binding update messages. The 
64-bit identification field, again, protects against replays and 
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allows the acknowledgment to be associated with a pending 
binding update. The N bit allows the recipient of the binding 
update to satisfy the A bit of the binding update, while inform- 
ing the updating agent that the update was not acceptable. 

Smooth Handoffs 

As mobile nodes move from one point of attachment to the 
next within the Internet, it would be nice if the transitions 
(called handoffs) were as smooth as possible. This could be a 
problem if datagrams heading toward one point of attachment 
were dropped because the mobile node had just left to attach 
somewhere else nearby. With route optimization such prob- 
lems will almost certainly arise, because there is no way that 
all correspondent nodes can instantaneously receive updated 
bindings reflecting the node's movement. Moreover, studies 
have shown that because of the way TCP works, the distrac- 
tion caused by dropping datagrams is magnified (by about a 
factor of two) [19]. 

Thus, it is important to deliver datagrams correctly even 
though they may arrive at the "wrong" care-of address. Route 
optimization enables the solution to this problem, by allowing 
previous foreign agents to maintain a binding for their former 
mobile visitors, showing a current care-of address for each. 
With such information, a previous foreign agent can reencap- 
sulate a datagram with the right care-of address and send it 
along to the mobile node. 

In order to obtain the maximum benefit from using route 
optimization to effect smooth handoffs from one foreign 
agent to the next, it would be best if the home agent were not 
involved. In fact, the handoff is targeted 
toward handling datagrams in flight with- 
out dropping them, but the home agent is 
often too far away to respond in time. If 
datagrams are being dropped for the hun- 
dreds of milliseconds it would take for a 
distant home agent to respond, megabits of 
data could be dropped. Recognizing this 
problem, we have designed a method by 
which cooperating foreign agents can, by 
authority of the mobile node, agree to per- 
form smooth handoffs before the new reg- 
istration has completed; see Fig. 15 for an 
illustration of the process. Essentially, 
when the mobile node moves to a new 
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point of attachment, it instructs its new foreign agent to send 
a binding update to its previous foreign agent. 

If the previous foreign. agent has no fresh binding for the 
mobile node, it can deliver the datagram to the home agent 
for further handling. This might conceivably be done by the 
simple expedient of decapsulating the datagram and sending it 
out for normal IP routing. The datagram would then be rout- 
ed to the home agent again. Such action, however, would 
probably cause routing loops whenever the home agent encap- 
sulates datagrams for delivery to a foreign agent which has 
lost track of one of its visiting mobile nodes. 

Instead, route optimization defines a way to use special 
tunnels, which indicate to the home agent the need for special 
handling. When a foreign agent wants to send a datagram 
back to the home agent (because the home address in the 
decapsulated datagram is not available), it instead encapsu- 
lates the datagram to be sent to the home agent. The newly 
encapsulated datagram uses the foreign agent's care-of 
address as the source IP address. Upon reception of the newly 
encapsulated datagram, the home agent compares the source 
IP address with the care-of address known in the binding cre- 
ated from the last registration. If the two addresses match, the 
home agent must not tunnel the datagram back to the care-of 
address. Otherwise, the home agent is allowed to retunnel the 
decapsulated result to the current care-of address known from 
the registration. 

Securing the Binding Updates 

Whenever a binding update is transmitted, it has to be accom- 
panied by an authentication extension. However, doing so is 
more challenging in the case of smooth handoffs. It is impor- 
tant to note that, again, foreign agents are considered anony- 
mous entities that are not trusted by the mobile node to do 
anything except follow protocol, and whose identity cannot 
necessarily be verified. The implication follows that the 
mobile node and foreign agent might share no special secret 
which can be used to build a security association. Even with- 
out a secret, however, the mobile node needs to persuade its 
previous foreign agent that the binding update (sent for the 
purpose of effecting a smooth handoff) has not been forged. 
The process of offering this persuasive evidence has been a 
challenging problem for designing the smooth handoff mecha- 
nism. The persuasive evidence possessed by the mobile node 
is called a registration key, and obtaining the registration key is 
accomplished by one of several means. 

In the interest of keeping the description to an appropriate 
size, the precise details of managing security between the 
mobile node and foreign agent will largely be omitted. How- 
ever, the overall procedure is as follows: 

• The foreign agent uses agent advertisement flags and 
extensions to provide information about the style of secu- 
rity it is prepared to offer the mobile node. 

• The mobile node selects one of a menu of possible 
actions, depending on availability. 

• The foreign agent responds to the mobile node's request, 
and if necessary cooperates with the mobile node to pro- 



vide smooth handoff operation and to 
obtain a registration key from the 
home agent. 

Our design of the smooth handoff proce- 
dure, using the binding update message as 
shown above, relies mostly on the mobile 
node to observe available methods and initi- 
ate their execution. The mobile node will 
know whether or not the foreign agent is 
willing to take part in the smooth handoff 
procedure by inspecting the advertised flags. 
In addition, the mobile node, when it first detects the foreign 
agent, will know immediately whether a mobility security asso- 
ciation is available with that agent. In that case, the mobile 
node can establish a registration key by the simple expedient of 
picking a good random number and encoding it for the foreign 
agent, using their shared secret. In this case, the registration 
has to include a mobile-foreign authentication extension. 

However, in our estimation the appropriate security associ- 
ation is a luxury unlikely to be encountered. Therefore, the 
mobile node may instead rely on the home agent to pick out a 
registration key for use by the mobile node and foreign agent. 
This, again, can be done in one of two ways. If the foreign agent 
and home agent share a security association, the foreign agent 
can request that the home agent encrypt a diligently selected 
registration key using that security association and transmit 
the result back to the foreign agent as part of the registration 
reply. The home agent informs the mobile node of the regis- 
tration key value by using the mobility security association 
which is always known to exist between the two nodes. 

If, on the other hand, the foreign agent does not have a 
security association with the home agent, but instead has a 
public key, it can send the public key to the home agent along 
with the registration, and accomplish much the same result as 
outlined in the last paragraph. Lastly, if the foreign agent does 
not have a public key, and has security associations with nei- 
ther the home agent nor the mobile node, there is still the 
possibility for a Diffie-Helbnan key exchange [20]. 

Performing smooth handoffs is complicated by the need to 
create a registration key in the absence of well-defined, stan- 
dardized, widely deployed security protocols. Nevertheless, it is 
hoped that the complication of the latter operation will not 
obscure the basic simplicity of the protocol, and that providing the 
protocol definition for each of a variety of feasible scenarios will 
broaden the appeal of smooth handoffs rather than cloud its future. 

IETF 

/n this section, we describe the pertinent details of the status of 
mobile IP in the standardization process, and interesting details 
about working groups arid the standardization process itself. 

The IETF is a somewhat loose confederation of numerous 
(over 60, at last count) working groups that meets three times 
a year. At these meetings, each working group may meet once 
or several times, or not at all. The working groups are divided 
into areas, each administered by an area director. For instance^ 
the Mobile IP working group is part of the routing area. The 
area director for each area has to review the proposals from 
each working group before they can be submitted for further 
consideration by the IETF at large. The area directors, taken 
together, also constitute another group called the Internet 
Engineering Steering Group (IESG). The IESG, upon recom- 
mendation of the particular area director sponsoring a proto- 
col document, tries to ensure a high degree of protocol 
quality, and to ensure that standardized protocols work well 
with each other. To put it mildly, this is a huge job, getting 
bigger all the time with the growth of the Internet. Complicat- 
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ing an already complex problem is 
the fact that Internet protocols 
suddenly represent big business, 
and a false step on the part of an 
area director or working group 
chair could easily result in an 
expensive lawsuit. 

The Mobile IP working group 
itself has had a long and at times 
contentious history. A succession 
of eminently competent working 
group chairs have fortunately man- 
aged to bring the process to a 
somewhat successful milestone, 
with the recent publication of the 
base mobile IP protocol docu- 
ments as proposed standards, and 
RFCs 2002-2006. A good place to 
look for such documents is on the 
IETF Web page, http://www. 
ietf.org. After some further con- 
sensus has been achieved and additional operational experi- 
ence gained, mobile IP may progress to a draft standard. This 
step should also be accompanied by a large increase in the 
number of deployed mobile IP systems in the Internet. For 
various reasons, mobile IP has not until now enjoyed its full 
potential. 

Route optimization, and the other protocol efforts 
described in the next section, are in a far more fluid state. 
These are still Internet drafts, not yet proposed standards. 

Current Topics 

IP VERSION 6 (IPv6) 

Although space does not permit a full exposition of the details 
of the proposed mobility protocols for IPv6, some overall dis- 
cussion is certainly in order. The current Internet draft [21] 
and a recent paper on the subject [22] should be consulted for 
full details. 

The IPv6 protocol [23, 24] and its attendant address con- 
figuration protocols (Neighbor Discovery [25] and Stateless 
Address Autoconfiguration [26]) form an almost perfect proto- 
col basis for mobile networking. The basic idea, that a mobile 
node is reachable by sending packets to its home network, and 
that the home agent sends packets from a home network to 
the mobile node's current care-of address, remains the same. 
Also, similar to the method used before (for IPv4, as described 
earlier), the home agent encapsulates packets for delivery 
from the home network to the care-of address. 

What has changed is that the mobile node now has an 
ensured capability to obtain a care-of address by using the 
above-mentioned address configuration protocols. Thus, there 
is a greatly reduced need for foreign agents, and they have 
been eliminated from the mobility support protocol. More- 
over, the idea from route optimization of supplying binding 
updates to correspondent nodes is able to be integrated nicely 
into IPv6 by using the newly defined destination options. Since 
destination options are inspected only by the destination, 
there is no performance penalty at intermediate routers for 
using them. Since such options can be placed into any IPv6 
packet, there is far less overhead involved in sending binding 
updates to correspondent nodes. The binding update can be 
included in any normal data packet that the mobile node 
would be sending to the correspondent node anyway. If a 
packet ever arrives at the home network, it will be encapsulat- 
ed and sent to the mobile node. Thus, when a mobile node 




Figure 1 5. Smooth handoff during registration. 



receives such an encapsulated IPv6 
packet, it can infer that the origi- 
nator of the decapsulated packet 
should receive a binding update 
(in a destination option) sent along 
with the very next packet transmit- 
ted to the originator. 

Just as with IPv4, binding 
updates need to be authenticated. 
What is different, however, is the 
expectation that every IPv6 node 
will be able to establish and main- 
tain security relationships as need- 
ed. In order to comply with the 
IPv6 specification, each node is 
required to implement IPv6 
authentication header [27] process- 
ing. Thus, the mobile node can 
assume that, by using security pro- 
tocols already specified, its binding 
updates will be confidently 
received by the correspondent nodes which need them. In 
IPv6, the mobile node is the only node authorized to supply 
binding updates to its correspondent nodes, and typically does 
so at the earliest reasonable time after moving to a new point 
of attachment to the IPv6 Internet. 

Firewalls and Packet Filtering Problems 

One of the biggest problems facing the deployment of mobile 
IP in today's Internet is that mobile nodes roaming in foreign 
enterprises look like interlopers, and the firewalls and border 
routers administered at the foreign domain are usually config- 
ured to interrupt traffic to and from interloper nodes. This is 
a reaction to the growing danger of protocol attacks and the 
desire to eliminate as many as possible of the hiding places 
favored by malicious users. 

So, for instance, a recent Internet draft [28] exhorts sys- 
tems administrators to perform ingress fdtering, by which is 
meant the action of disallowing datagrams entry into the 
Internet from any leaf domain, unless those datagrams con- 
form to expectations about their source IP address. By doing 
so, the Internet is considered better protected from domains 
harboring malicious users, because users sending datagrams 
from the domain will not be able to impersonate users from 
the ingress-filtering domains. 

This, of course, is anathema for mobile IP. Any mobile 
node in a foreign domain is going to have a source IP address 
which doesn't "look right" to such ingress-filtering border 
routers. One idea is to allow the mobile nodes to issue encap- 
sulated datagrams using their care-of addresses as the outer 
source IP addresses. Note that using the care-of address as 
the source IP address of the original datagram is typically a 
losing proposition, since the correspondent node is keeping 
track of its sessions by way of the mobile node's home address, 
not its care-of address. 

The downside of this encapsulation approach is that IPv4 
correspondent nodes are unlikely to be able to decapsulate 
such datagrams, so the mobile node has to find another likely 
target for the encapsulated datagrams, and there aren't many 
commonly available today. One possible target would be the 
mobile node's home agent, which is pretty much guaranteed 
to be able to perform decapsulation. Obviously, this intro- 
duces yet another inefficiency in the routing of datagrams 
from mobile nodes, and there is work actively in progress to 
try to find other solutions to this problem. 

An associated difficulty is the problem of allowing the 
mobile node to send datagrams into its home domain. The 
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border routers protecting the home domain are likely to disal- 
low any datagrams which seem to have a source IP address 
belonging to an internal subnet of the home domain. This 
problem is probably amenable to solution by way of some pro- 
tocol which informs the (probably specialized) border routers 
about those source IP addresses which are allowed to exter- 
nally originate datagrams into the home domain. It is also fea- 
sible for border routers to encapsulate such datagrams for 
delivery to an enterprise home agent [29, 30], 

As a matter of administrative convenience, it is likely that 
the firewalls will be configured to allow all datagrams in as 
long as they are addressed to a home agent, protocol UDP, 
port 434. This will at least enable mobile IP to get the regis- 
trations in from the global Internet to the home agents. From 
the considerations in the previous paragraphs, it is also rea- 
sonable to expect that the local network administrator will 
demand a very high degree of reliability and code quality from 
the home agent. 

Simultaneous Bindings 

One feature of mobile IP which has not been stressed in this 
article is the use of multiple simultaneous registrations. The 
base specification permits a mobile node to register more than 
one care-of address at the same time, and to deregister a spe- 
cific care-of addresses as necessary, by setting the S bit in the 
registration request message. When there is more than one care- 
of address active for a mobile node, the home agent is instruct- 
ed to send a duplicated encapsulated datagram to each care-of 
address. Presumably, then, the mobile node will receive the 
decapsulated result at each of the several care-of addresses. 

This unusual behavior still does technically conform to 
router and host requirements for IP, because the IP specifica- 
tion allows duplicating of datagrams. There are times when 
such behavior is justified for certain classes of links. More- 
over, it is easier from a network-layer protocol standpoint not 
to require that network nodes enforce any policy ensuring that 
datagrams are not duplicated. Removing duplicates is typically 
done by transport- or application-layer protocols whenever it 
makes a difference. In the case of mobile IP, the original jus- 
tification for simultaneous registrations was that many wire- 
less links are error-prone, and certainly receiving noisy signals 
from multiple sources can often allow a target to reconstruct 
the original signal more accurately. 

Simultaneous registrations, while still holding promise for 
the improved handling of IP wireless connectivity, have not 



been available in any implementation known to the author. 
Thus, this optional feature should be considered a possible 
future benefit. The unavailability of simultaneous registration 
is probably mostly due to the slow dissemination of wireless 
local area network (LAN) technology into the marketplace, 
considering that wireless connectivity was the motivating fac- 
tor for the inclusion of the feature in the first place. 

Regionalized Registration 

The concern has been raised that, for highly mobile com- 
puters, too much traffic between the visited and home net- 
works would be generated by the registration process. Given 
the current state of the protocol, several counterarguments 
can be made against that objection: 
•Unless route optimization is enabled, the normal traffic 
of encapsulated datagrams from the home agent will 
make the control traffic from the registration seem neg- 
ligible. 

•The mobile IP specification technically allows registra- 
tions to be issued no more often than once per second 
per mobile node. That should not present too much 
network traffic. 

Thus, the problem of frequent registration is probably not 
terribly important until route optimization is more fully 
deployed. However, there are other factors that must be con- 
sidered. First, with some diligent management of the local 
connectivity available to the mobile node and buffering of 
datagrams that have to be delivered, one can get some of the 
benefit of smooth handoffs without implementing route opti- 
mization in the foreign agents (e.g., see [31]). 

In fact, it is also possible to have a collection of foreign 
agents joined together in a multicast group, and then subse- 
quently allow the mobile node to use the multicast IP address 
as its care-of address. In either case, work is necessary to 
cause each foreign agent to buffer each datagram, at least 
momentarily, in case the mobile node decides to depart the 
previous foreign agent from which the datagram was expected 
to be transmitted to the mobile node. Also, notably, any such 
approach requires new protocol to be operated by the foreign 
agents, and the schemes are really intended to only be used in 
a two-level hierarchy. It is an open question whether doing 
the buffering is better in conjunction with the above-men- 
tioned methods or with route optimization techniques. 

Another alternative [32] establishes a hierarchy of foreign 
agents, and advertises multiple foreign agents in the agent 
advertisement. Then registrations can be localized to the for- 
eign agent which is the lowest common ancestor of the care-of 
addresses at the two points of attachment of interest. To 
enable this, the mobile node has to figure out how high up the 
tree its new registration has to go, and then arrange for the 
transmission of the registration to each level of the hierarchy 
between itself and the closest common ancestor between its 
new and previous care-of addresses. 

Consider the illustration in Fig. 16. While it was using the 
services of foreign agent FA 7 , the mobile node was receiving 
agent advertisements describing the hierarchical lineage FA 7 , 
FA4, FA2, FA h and had caused a registration, now specialized 
for this purpose, to be transmitted to each of those foreign 
agents as well as its home agent. Its home agent believes the 
mobile node is located at care-of address FA^ foreign agent 
FA X believes the mobile node is located at foreign agent FA2, 
and so on, until foreign agent FA 7 actually knows the where- 
abouts of the mobile node. When the mobile node moves to 
foreign agent FAg, it only has to cause the new hierarchical 
registration to propagate as far as FA 4 . When the mobile 
node moves to foreign agent FA 9 , it receives advertisements 
indicating the lineage FA9, FA$, FA 3) FAj. By comparing the 
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previous and current lineage, the mobile node determines that 
it has to cause the registration to propagate up the hierarchy 
to FAi, but the registration still does not have to reach the 
home agent. The home agent can, in this scenario, be consid- 
ered the "ultimate" care-of address of the mobile node. Note 
also that, as a result of the differing views of the hierarchical 
agents about the mobile node's care-of address, the original 
datagram must be relayed to a number of intermediate nodes 
in the hierarchy; each is then charged with the responsibility 
of retunneling the datagram if necessary to the next lower 
level of the hierarchy. 

Summary 

/n this article, we have explored most of the technical details 
of mobile IP, an extension to IP which allows mobile nodes 
to roam transparently from place to place within the Internet, 
usually with no discernible disruption of service. Mobile IP 
affects the routing of datagrams within the Internet, by effec- 
tively allowing the home agent to create a tunnel, using 
encapsulation, between the mobile node's home network and 
whatever care-of address happens to identify its current point 
of attachment. The advertisement and registration protocols 
are described in detail, and variations on the tunneling proto- 
cols shown. 

Tunneling from the home agent introduces additional rout- 
ing links into the communication paths between mobile nodes 
and their correspondent nodes. This suboptimal routing can 
be cured, with the cooperation of the correspondent nodes, by 
allowing the dissemination of binding updates to each active 
correspondent using the route optimization protocols. Binding 
updates allow the correspondents to tunnel datagrams directly 
to the mobile node's care-of address instead of relying on the 
home agent for this function. With virtually the same route 
optimization techniques, foreign agents can cooperate with 
the mobile node to effect smooth handoffs, being careful not 
to drop any datagrams even when the mobile node has moved 
away from the care-of address receiving the datagrams. 

Mobile IP and route optimization both must be subject to 
rigid requirements for authentication of the claimed care-of 
addresses, because otherwise malicious hosts could disrupt or 
completely usurp communications with the mobile node. 
These new requirements have fostered the inclusion of simple 
yet relatively new techniques into these protocols to ensure 
that the care-of address information has been sent by an 
authorized entity. 

Aspects of the standardization process within the IETF, 
which have had a major impact on the development of mobile 
IP, have been described. Finally, we describe some areas of 
current and supplemental interest related to mobile IP. The 
problems facing mobile IP in the realm of secure enterprise 
computing are detailed, especially regarding ingress filtering 
and firewalls. Mobility support for IPv6 is outlined in its gross 
aspect. The possible future benefits of simultaneous registra- 
tions are briefly explained, and several ways to localize regis- 
tration requests are described. 

Final Words 

e hope this brief introduction to mobile IP will engender 
interest in the solution to the remaining problems which 
continue to challenge deployment of the protocol, particularly 
in the areas involving existing enterprise security facilities using 
firewalls and recent packet filtering techniques. Participation 
on the mobile IP mailing list is encouraged; the mailing list can 
be joined by sending mail to majordomo@Smallworks.COM, 
including the line "subscribe mobile-ip" in the body of the 



message. One can keep up with general events within the 
IETF by selecting the appropriate links on the Web page 
http://www.ietf.org. The author will also gladly answer elec- 
tronic mail sent to cperkins@corp.sun.com. Acknowledgment 
is due to Vipul Gupta, without whom this article could never 
have been finished even in the time it took to do so, and to the 
many people who have contributed greatly to the effort of pro- 
ducing and improving the mobile IP specifications. 
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